-
-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] move lib/include dir search into @rules in native_toolchain.py #6271
[WIP] move lib/include dir search into @rules in native_toolchain.py #6271
Conversation
} | ||
|
||
def as_execute_process_request(self, more_args=None): | ||
argv = [self.exe_filename] + self.extra_args + (more_args or []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
more_args
can be a tuple here to eliminate the or
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only sort-of. If you want to be defensive, this is appropriate. The caller can explicitly pass None
.
@@ -90,7 +90,7 @@ def linker(self, platform): | |||
path_entries=self.path_entries, | |||
exe_filename=platform.resolve_platform_specific( | |||
self._PLATFORM_SPECIFIC_LINKER_NAME), | |||
library_dirs=[], | |||
runtime_library_dirs=[], | |||
linking_library_dirs=[], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im slightly confused on the difference here between runtime_library_dirs
and linking_library_dirs
. Is the latter for static libs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Directories containing shared libraries that must be on the runtime library search path.
(this is LD_LIBRARY_PATH
or DYLD_LIBRARY_PATH
) vs Directories to search for libraries needed at link time.
(this is LIBRARY_PATH
, it's for both static and shared libs).
def parse_known_lib_dirs(compiler_search_request): | ||
# FIXME: convert this to using `copy()` when #6269 is merged. | ||
cmplr = compiler_search_request.compiler | ||
print_search_dirs_exe = type(cmplr)(path_entries=cmplr.path_entries, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be tuples to conform to other compiler instantiations in this changeset. I may be missing something, but its good to have consistency. Also, not sure how I feel about this construction using type
. Might be cleaner to have this as a class method on the compiler class, however I don't have any explicit reason to change this beyond Python conventions/readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to classmethod over constructor here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned that this should be using a .copy()
method with an explicit comment -- that has now been implemented and removes all of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If by "tuples" you mean positional arguments, that's much more brittle to future changes in the fields of the datatype
than explicitly specifying keyword arguments in a .copy()
call.
# c_compiler=c_compiler.copy(include_dirs=compiler_search_output.include_dirs.dirs), | ||
# c_linker=c_linker.copy(linking_library_dirs=compiler_search_output.lib_dirs.dirs))) | ||
resolved_c_toolchain = CToolchain( | ||
c_compiler=CCompiler(path_entries=c_compiler.path_entries, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tuples here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is meant by "tuples" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this! This is a huge improvement to the native toolchain and makes the compile environment way easier to understand. I left a few comments/questions but no blockers. Feel free to take or leave the suggestions.
Also, I would like to see one more approval by a developer who is more familiar with rules and snapshots. I am still wrapping my head around these concepts, however details of rules aside, these changes look good to me.
} | ||
|
||
def as_execute_process_request(self, more_args=None): | ||
argv = [self.exe_filename] + self.extra_args + (more_args or []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only sort-of. If you want to be defensive, this is appropriate. The caller can explicitly pass None
.
]), LinkerMixin): | ||
|
||
@property | ||
def with_tupled_collections(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 3 with_tupled_collections
are unused - kill. Additionally, with_*
reads like a verb and not like a noun, so either @property
is not appropriate or the naming is suboptimal.
def parse_known_lib_dirs(compiler_search_request): | ||
# FIXME: convert this to using `copy()` when #6269 is merged. | ||
cmplr = compiler_search_request.compiler | ||
print_search_dirs_exe = type(cmplr)(path_entries=cmplr.path_entries, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to classmethod over constructor here.
fbdac6e
to
e582161
Compare
Closing due to being stale, such as no longer using |
WIP because I'm waiting on #6374 to use the datatype default value helpers.
Problem
Searching for lib and include directories to provide to our compilers and linkers is still pretty brittle. Part of this is that while we provide include dirs through e.g. the
CPATH
environment variable, clang and gcc will still prefer "system" include dirs they find themselves over ours, and this leads to e.g. breakages across untested linux platforms.Solution
-nostdinc
,-nobuiltininc
(this is osx-only), and-nostdinc++
where possible to our compiler command lines innative_toolchain.py
to stop them from searching for include directories by themselves.LibcDev
andParseSearchDirs
to move al(most al)l toolchain configuration intonative_toolchain.py
, where we search for lib dirs as before (by parsing the output of a compiler executable invocation), and also introduce include path searching in the same way, but invoking the compiler with a different command.library_dirs
fromExecutable
to be instead namedruntime_library_dirs
.Result
The logic from
LibcDev
andParseSearchDirs
is now spread into several@rule
s innative_toolchain.py
, and that functionality is now much easier to access. We now separately search for include directories, which allows us to turn on-nostdinc
/etc and have deeper control over what resources we pull in for compilation.